The factory can create, sign, and finalize the warning transaction.

The factory can create, sign, and finalize the redirection transaction.

Add an extra flag to 'DelayedPayoutTxReceiverService.getReceivers(..)'
to control the tx fee precision, and refactor to use an EnumSet of flags
activated by particular date, instead of just passing boolean args. This
new 'PRECISE_FEES' flag is currently set to activate at the same time as
the v5 protocol upgrade (though it can be used independently).

When present, the flag changes the receiver list calculation as follows:

 1) Spendable amount depends on individual output ScriptPubKey sizes,
    instead of all outputs assumed to cost 32 bytes each (P2SH cost);
 2) Base cost of DPT is that of the signed instead of unsigned tx (v4
    protocol only - redirect tx base cost is always for the signed tx);
 3) Increase in spendable amount from saved tx fees after filtering out
    the small outputs is taken into account;
 4) Small outputs are filtered out pre-adjustment upwards, rather than
    post-adjustment, so that they don't get erroneously included;
 5) The balance given to the LBM takes the tx fee cost of his output
    into account.

Additionally, restrict the fee bump addresses of the peer's warning and
redirect txs to be P2WPKH, for more predictable tx fee rates.

Make sure the 'signedClaimTx' & 'finalized(Warning|Redirect)Tx' fields
of the 'ProcessModel' & 'TradingPeer' models are persisted properly in
the respective proto objects. To this end, store them serialised as byte
arrays instead of Transaction objects.

(Also clean up the Lombok annotations slightly.)

Add checks that we're not running the v5 protocol, everywhere a missing
delayed payout tx would cause errors or warnings to appear in either the
logs or the Pending Trades or Trade Details views, for a v5 trade that
completes normally.

Also add both the buyer's & seller's redirect & warning txs to the Trade
Details view, in place of the missing DPT, as well as the claim tx if
it's present. (The latter is created & signed at the point of use.) Add
suitable 'get*(BtcWalletService)' methods to 'Trade' for that purpose.

Make 'aesKey' method parameters @nullable where obviously applicable,
for consistency (as it was missed out in a number of places). Also make
the v5-protocol-specific fee bump fields of 'InputsForDepositTxRequest'
@nullable, as expected.

Make sure 'TransactionAwareTrade::isRelatedToTransaction' returns true
for warning, redirect & claim txs belonging to the given trade. Also
optimise the method somewhat by short circuiting on a wider class of txs
than those with zero locktime, when ruling out that the tx is a delayed
payout or warning tx. The previous short circuit test was inadequate due
to the fact that a lot of wallets, such as Sparrow, set a nonzero
locktime on all txs by default, to prevent fee sniping.

Also modify 'TransactionAwareTradable::bucketIndex' to place the new
staged txs in the (global) delayed payout tx bucket, so that they get
past the related transactions filter, used to speed up the pairing of
txs with tradables.

Since the multisig escrow outputs of the deposit & warning txs do not
belong to the user, bitcoinj won't pick up any txs spending them unless
a corresponding watched script (the ScriptPubKey) is added to the
wallet. To this end, provide a trade task to add watched scripts for
those three outputs, which runs just before the client or the peer might
broadcast the deposit tx. Also remove them upon withdrawal of funds at
the end of the trade (closed normally or through a dispute).

We need to add watched scripts for the deposit tx output and both the
user's and the peer's warning tx outputs, so that the peer's warning,
redirect and claim txs are all picked up, regardless of any message sent
to the client.

TODO: Possibly find a way to clear out old watched scripts from failed
 trades, as they will otherwise remain in the user's wallet permanently,
 creating a growing burden for the wallet. Also, we should possibly re-
 add all the watched scripts if the wallet is restored from seed.

Ensure 'TransactionsListItem' recognises warning, redirect & claim txs
and displays appropriate details messages for them. Redirect txs are
made to show the same "Refund collateral" details message as delayed
payout txs and don't distinguish between the user's or peer's tx,
whereas warning & claim tx details do distinguish between them.

Also ensure the correct amounts are displayed in the Transaction view,
when watched scripts are present in the wallet, by changing
'WalletService::getValueSent(To|From)MeForTransaction' not to include
watched outputs or inputs in their respective sums.

Ensure claim txs broadcast by the peer are correctly linked to the trade
and display correctly in the Transactions view, by changing
'BisqRiskAnalysis' not to deem txs with a relative lock time as risky,
as that interferes with the v5 trade protocol.

Finally, make the Trade Details window resilient to missing peer's
redirect & warning tx from old trades, which could be cleared out as
sensitive data, and prevent it from incorrectly displaying the claim tx
as the multisig payout tx (and similarly for the Transactions view).

Also update the expected signed tx sizes accordingly, and require that
the peer provides a low-R signature for them, so that they're never
bigger than expected. (No such requirement is made of any of the txs in
the current v4 protocol, to ensure backwards compatibility.)

Add the 4 values 'WARNING_SENT(_BY_PEER)' & 'ESCROW_CLAIMED(_BY_PEER)'
(all unused at present) to the 'Trade.DisputeState' enum, and update the
proto. The new states are not classed as arbitrated, as arbitration is
only deemed to occur once a redirect tx has been published (and that's
intended to reuse the existing 'REFUND_REQUEST*' dispute states of the
current v4 protocol). But they are an escalation beyond mediation, as
they spend the escrow, and thus disable both the buyer and seller
payment confirmation. Accordingly, add a 'DisputeState::isEscalated'
predicate to include the new states in addition to the arbitrated ones.

Adapt the existing workflow of starting a second-round arbitration
process, upon mediation failure, to the v5 trade protocol, by giving the
trader an option to broadcast his warning tx. This replaces the current
(tertiary) action of broadcasting the (v4 protocol) delayed payout tx to
start arbitration, on the mediation result popup. Instead, the trader
must now wait for the peer to see the warning tx and actually start
arbitration by broadcasting his redirect tx. (This second part is not
yet implemented.)

Also clean up 'DisputeValidation' slightly and prevent the errant
display of a duplicate-DPT-detected message in the event that a dispute
has a missing delayed payout txId (as is currently the case for v5
protocol trades). Fix the logic similarly for missing trade IDs &
deposit txIds.

TODO: Allow peer to start arbitration by broadcasting his redirect tx,
 upon detection (via a suitable listener) of a warning tx broadcast.

Provide a 'SetupWarningTxListener' trade task, which runs at the opening
of the trade and upon initialisation of the trade manager at application
startup. It adds a listener which picks up either warning tx and updates
the dispute state to 'WARNING_SENT(_BY_PEER)', as appropriate.

As the peer's warning tx may be unknown (at least in the unlikely event
that sensitive data was cleared out of an unfailed trade), the listener
detects any spend of the deposit tx escrow output. (This functionality
will also be needed to pick up the peer's claim tx, which has a
completely unknown txId.) To this end, provide a new listener type,
'OutputSpendConfidenceListener', which can be added to or removed from a
'WalletService' instance and detects change in the confidence of any tx
spending the provided (non-detached) 'TranactionOutput' instance.

(Also do some minor cleanup of the 'WalletService' class.)

When either of the trade peers publishes his warning tx, reflect that in
the info panel of the trade step view, providing a red "Redirect to
arbitration" or a (possibly greyed out) green "Claim trade collateral"
button, in place of the usual get-help/open-dispute button. Add four new
values to the 'TradeStepInfo.State' enum to distiguish whose warning tx
was published and whether the corresponding claim tx is still locked.
Provide (currently unimplemented) button action stubs to open a popup to
claim/redirect.

Also do some minor cleanup of 'TradeStepView' and make sure the method
'DisputeManager::checkForMediatedTradePayout' closes the mediation
ticket upon publishing of either warning tx, not just upon starting
arbitration or receiving a payout.

Rename 'SetupWarningTxListener' to 'SetupStagedTxListeners' and add code
to provide a second listener for the redirect or claim tx, upon firing
of the first listener. Set the trade dispute state to one of the four
states 'REFUND_REQUEST(_STARTED_BY_PEER)' or 'ESCROW_CLAIMED(_BY_PEER)',
as appropriate, upon firing of the downstream listener. Also, restore
the peer's redirect or warning tx in the unlikely event that they were
cleared out as sensitive data, and fill in the peer's claim tx if it
gets picked up. Add a proto field to persist the latter, in order to
show it in the details window of a past trade.

Make sure that the peer's staged txs don't get subsequently removed as
sensitive data if the trade wound up in a dispute and any staged txs
were broadcast. Similarly, suppress the removal of watched scripts in
that case, to prevent staged txs disappearing if there's an SPV resync.

Finally, add a missing 'SetupStagedTxListeners' trade task item to the
'PreparedTxBuyerSignaturesMessage' handler of the v5 seller-as-maker
protocol (overriding super), as the listeners weren't being set up at
the start of the trade in that case.

Make the filtering methods 'isPossible(RedirectOrClaimTx|EscrowSpend)',
used to speed up the Transactions view, lenient towards segwit txs that
have missing witness data. This appears to be the case for a lot of txs
fetched from the network by bitcoinj, including all the segwit txs in
the wallet after an SPV resync.

Since the witness data of a peer's claim tx (picked up by bitcoinj) may
in fact be missing, rename the field 'TradingPeer.signedClaimTx' to
'claimTx', along with corresponding proto field.

Finally, make sure the correct details message is shown for refund agent
payout txs, for v5 protocol trades in the Transactions view, by changing
the order of some of the nested if-else branches, in order to avoid an
unwanted '!trade.hasV5Protocol()' clause.

Implement the redirect-to-arbitration & claim buttons in the trade step
view, allowing the warned peer to publish the redirect tx and open a
refund dispute, or the user to close the trade by publishing the claim
tx if an unresponsive peer. To this end, add '(warning|redirect)TxId'
fields to the 'Dispute' DTO and corresponding proto, to use in place of
the (now null) 'delayedPayoutTxId' field. The new fields allow the
refund agent to validate the tx chain in the case of the v5 protocol
(using the Mempool service to make sure the redirect tx is valid and
published/confirmed -- not yet implemented) and guard against replay
attacks. Update the validation logic accordingly (& add some TODOs).

Additionally, tidy up 'DisputeSummaryWindow' a little and fix a bug in
'SetupStagedTxListeners' preventing the redirect/claim tx listener from
firing after the warning tx appears, until an application restart. Also
ensure that it closes the trade instead of merely updating the dispute
state, when a claim tx is picked up.

TODO: Improve popup messages & fix arbtrator tx chain validation logic.

Replace the large tuple of 'Map<String, Set<String>>' objects, built by
'DisputeValidation.getTestReplayHashMaps' to detect triplicate trade &
tx IDs across all the disputes, with a map from dispute field refs to
multimaps of all the corresponding fieldValue-disputeUid mappings. This
eliminates a lot of the repetition building the individual hash maps of
the tuple and consuming them, as a map was needed for each ID field of
'Dispute' with triplicate detection, namely the five fields:

  tradeId, delayedPayoutTxId, warningTxId, redirectTxId, depositTxId.

For this purpose, create a private 'DisputeIdField' enum of field refs
encapsulating the field name (for log & error messages) and getter.

(Triplicated rather than duplicated IDs are being detected because the
dispute DTOs come in pairs: one for the buyer and one for the seller.)

Simplify and factor out a 'getDisputeGroupsByTrade()' method, to group
disputes by trade ID, from the 'show(Compact|Full)Report()' method
logic. Also fix a broken comparator on the Market column, that missed a
'CurrencyUtil::getCurrencyPair' application to the RHS parameter.

Additionally, do some minor cleanup of the class:

  Make fields final where possible, unbox primitive, convert statement
  to expression lambdas, simplify some if-else branches, use a loop in
  in place of 'forEach' to allow local variable mutation, formatting.

Make sure the published warning & redirect txIds of a refund dispute
show up in the details window, in place of the DPT ID for v4 protocol
trades. (Unlike the latter, the fields are missing from the details for
mediation disputes, as it isn't known which combination of staged txs
will be published, if any.)

Also make sure the two txIds are filterable on, by adding them to the
'DisputeView.FilterResult' enum and 'getFilterResult(..)' method.

Make sure the logic to fetch the chain of trade txs from mempool.space,
and validate the receiver list, works in the case of the v5 protocol. In
that case, the published warning & redirect txs replace the DPT, giving
five txs in the chain instead of four. Ensure that in both cases the
number of confirmations of the last tx (DPT for v4, redirect tx for v5)
shows up in Dispute Summary window (outside of regtest). Also fix a bug
validating the outputs of the last tx, where it failed to iterate
through the receiver tuples correctly, which would have prevented it
from ever working in production (as there's more than one receiver).

Finally, make the dispute validation more strict about which txId fields
it allows to be null vs non-null, so that the DPT ID is always null when
the redirect or warning txId fields are set (signifying a v5 protocol
trade for refund disputes). Disallow use of the legacy BM in that case
as well, for safety, as it should never be used for new trades.

Enhance the tx chain validation logic in 'DisputeSummaryWindow' to check
that the deposit tx funds no less than the total trade collateral of the
contract, and that the BM won't receive less than the proposed refund,
due to excessive tx fees. This is to guard against a malicious pair of
traders who could attempt to trick the refund agent into paying out more
than they deposited, by supplying a mismatched contract, or (less
feasibly) colluding with a miner and using an unreasonably high mining
fee to steal some of the funds that should go to the BM.

Also verify that the DPT output address matches the donation address in
the 'Dispute' DTO, for any dispute using the legacy BM, as that option
is not forbidden for v4 protocol trades.

Finally, validate the txId string passed in the URL to mempool.space
from the methods 'MempoolHttpClient::(getTxDetails|requestTxAsHex)', for
safety and to avoid GET requests like '/null' or '/null/hex' if the txId
is null.

Deduplicate the public key used in the claim path of the warning escrow
output redeem script, of the v5 protocol, reducing the size of the
redirect & claim txs by 8 vbytes (32 WUs) each. The claim public key
doubles up as the trader's 2-of-2 multisig public key, used for both the
regular escrow output of the deposit tx and the redirection spend path
of the warning escrow output, so it may be reused through some
manipulation of the bitcoin stack.

Also reverse the order of the buyer & seller pubKeys & signatures, so
that the buyer signature is always higher up in the stack, for
consistency with the deposit tx redeem script.

This leads to the following two warning escrow output redeem scripts,
structured slightly differently:

Buyer's warning escrow output redeem script:

  <buyerPubKey> OP_SWAP
  OP_IF
    2 <sellerPubKey> OP_ROT 2 OP_CHECKMULTISIG
  OP_ELSE
    <claimDelay> OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG
  OP_ENDIF

Seller's warning escrow output redeem script:

  <sellerPubKey> OP_SWAP
  OP_IF
    2 OP_SWAP <buyerPubKey> 2 OP_CHECKMULTISIG
  OP_ELSE
    <claimDelay> OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG
  OP_ENDIF